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CHAPTER  1 


INTRODUCTION 


The  Ada  implementation  described  above  vas  tested  according  to  the  Ada 
Validation  Procedures  [Pro90]  against  the  Ada  Standard  [Ada83]  using  the 
current  Ada  Compiler  Validation  Capability  (ACVC).  This  Validation  Summary 
Report  (VSR)  gives  an  account  of  the  testing  of  this  Ada  implementation. 

For  any  technical  terms  used  in  this  report,  the  reader  is  referred  to 
[Pro90].  A  detailed  description  of  the  ACVC  may  be  found  in  the  current 
ACVC  User's  Guide  [UG89]. 


1.1  USE  OF  THIS  VALIDATION  SUMMARY  REPORT 

Consistent  with  the  national  laws  of  the  originating  country,  the  Ada 
Certification  Body  may  make  full  and  free  public  disclosure  of  this  report. 
It  the  United  States,  this  is  provided  in  accordance  with  the  "Freedom  of 
Information  Act"  (5  U.S.C.  #552).  The  results  of  this  validation  apply 
only  to  the  computers,  operating  systems,  and  compiler  versions  identified 
in  this  report. 

The  organizations  represented  on  the  signature  page  of  this  report  do  not 
represent  or  warrant  that  all  statements  set  forth  in  this  report  are 
accurate  and  complete,  or  that  the  subject  implementation  has  no 
nonconformi ties  to  the  Ada  Standard  other  than  those  presented.  Copies  of 
this  report  are  available  to  the  public  from  the  AVF  which  performed  this 
validation  or  from: 

National  Technical  Information  Service 
5285  Port  Royal  Road 
Springfield  VA  22161 


Questions  regarding  this  report  or  the  validation  test  results  should  be 
directed  to  the  AVF  which  performed  this  validation  or  to: 

Ada  Validation  Organization 
Institute  for  Defense  Analyses 
1801  North  Beauregard  Street 
Alexandria  VA  22311 


1-1 


INTRODUCTION 


1 . 2  REFERENCES 


[Ada83]  Reference  Manual  for  the  Ada  Programming  Language, 

ANSI/MIL-STD-1815A,  February  1983  and  ISO  8652-1987. 

[Pro90]  Ada  Compiler  Validation  Procedures,  Version  2.1,  Ada  Joint  Program 
Office,  August  1990. 

[UG89]  Ada  Compiler  Validation  Capability  User's  Guide,  21  June  1989. 


1.3  AC VC  TEST  CLASSES 

Compliance  of  Ada  implementations  is  tested  by  means  of  the  ACVC.  The  ACVC 
contains  a  collection  of  test  programs  structured  into  six  test  classes: 

A,  B,  C,  D,  E,  and  L.  The  first  letter  of  a  test  name  identifies  the  class 
to  which  it  belongs.  Class  A,  C,  D,  and  E  tests  are  executable.  Class  B 
and  class  L  tests  are  expected  to  produce  errors  at  compile  time  and  link 
time,  respectively. 

The  executable  tests  are  written  in  a  self-checking  manner  and  produce  a 
PASSED,  FAILED,  or  NOT  APPLICABLE  message  indicating  the  result  when  they 
are  executed.  Three  Ada  library  units,  the  packages  REPORT  and  SPPRT13, 
and  the  procedure  CHECKFILE  are  used  for  this  purpose.  The  package  REPORT 
also  provides  a  set  of  identity  functions  used  to  defeat  some  compiler 
optimizations  allowed  by  the  Ada  Standard  that  would  circumvent  a  test 
objective.  The  package  SPPRT13  is  used  by  many  tests  for  Chapter  13  of  the 
Ada  Standard.  The  procedure  CHECK_FILE  is  used  to  check  the  contents  of 
text  files  written  by  some  of  the  Class  C  tests  for  Chapter  14  of  the  Ada 
Standard.  The  operation  of  REPORT  and  CHECKFILE  is  checked  by  a  set  of 
executable  tests.  If  these  units  are  not  operating  correctly,  validation 
testing  is  discontinued. 

Class  B  tests  check  that  a  compiler  detects  illegal  language  usage.  Class 
B  tests  are  not  executable.  Each  test  in  this  class  is  compiled  and  the 
resulting  compilation  listing  is  examined  to  verify  that  all  violations  of 
the  Ada  Standard  arc  detected.  Some  of  the  class  B  tests  contain  legal  Ada 
code  which  must  not  be  flagged  illegal  by  the  compiler.  This  behavior  is 
also  verified. 

Class  L  tests  check  that  an  Ada  implementation  correctly  detects  violation 
of  the  Ada  Standard  involving  multiple,  separately  compiled  units.  Errors 
are  expected  at  link  time,  and  execution  is  attempted. 

In  some  tests  of  the  ACVC,  certain  macro  strings  have  to  be  replaced  by 
implementation-specific  values  —  for  example,  the  largest  integer.  A  list 
of  the  values  used  for  this  implementation  is  provided  in  Appendix  A.  In 
addition  to  these  anticipated  test  modifications,  additional  changes  may  be 
required  to  remove  unforeseen  conflicts  between  the  tests  and 
implementation-dependent  characteristics.  The  modifications  required  for 
this  implementation  are  described  in  section  2.3. 
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For  each  Ada  implementation,  a  customized  test  suite  is  produced  by  the 
AVF.  This  customization  consists  of  making  the  modifications  described  in 
the  preceding  paragraph,  removing  withdrawn  tests  (see  section  2.1)  and, 
possibly  some  inapplicable  tests  (see  Section  2.2  and  [UG89]). 

In  order  to  pass  an  ACVC  an  Ada  implementation  must  process  each  test  of 
the  customized  test  suite  according  to  the  Ada  Standard. 


1.4  DEFINITION  OF  TERMS 


Ada  Compiler 


Ada  Compiler 
Validation 
Capability 
(ACVC) 

Ada 

Implementation 

Ada  Joint 
Program 
Office  (AJPO) 

Ada 

Validation 
Facility  (AVF) 

Ada 

Validation 

Organization 

(AVO) 

Compliance  of 
an  Ada 

Implementation 

Computer 

System 


The  software  and  any  needed  hardware  that  have  to  be  added 
to  a  given  host  and  target  computer  system  to  allow 
transformation  of  Ada  programs  into  executable  form  and 
execution  thereof. 

The  means  for  testing  compliance  of  Ada  implementations, 
consisting  of  the  test  suite,  the  support  programs,  the  ACVC 
user's  guide  and  the  template  for  the  validation  summary 
report . 

An  Ada  compiler  with  its  host  computer  system  and  its 
target  computer  system. 

The  part  of  the  certification  body  which  provides  policy  and 
guidance  for  the  Ada  certification  system. 


The  part  of  the  certification  body  which  carries  out  the 
procedures  required  to  establish  the  compliance  of  an  Ada 
implementation. 

The  part  of  the  certification  body  that  provides  technical 
guidance  for  operations  of  the  Ada  certification  system. 


The  ability  of  the  implementation  to  pass  an  ACVC  version. 


A  functional  unit,  consisting  of  one  or  more  computers  and 
associated  software,  that  uses  common  storage  for  all  or 
part  of  a  program  and  also  for  all  or  part  of  the  data 
necessary  for  the  execution  of  the  program;  executes 
user-written  or  user-designated  programs;  performs 
user-designated  data  manipulation,  including  arithmetic 
operations  and  logic  operations;  and  that  can  execute 
programs  that  modify  themselves  during  execution.  A 
computer  system  may  be  a  stand-alone  unit  or  may  consist  of 
several  inter-connected  units. 
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Conformity 


Customer 


Declaration  of 
Conformance 


Host  Computer 
System 

Inapplicable 

test 

ISO 

Operating 

System 


Target 

Computer 

System 

Validated  Ada 
Compiler 

Validated  Ada 
Implementation 

Validation 


Withdrawn 

test 


Fulfillment 

by  a  product,  process  or 

service 

of 

all 

requirements 

specified . 

An  individual  or  corporate  entity  who 

enters 

into 

an 

agreement 

with  an  AVF  which  specifies 

the 

terms 

and 

conditions  for  AVF  services  (of  any  kind)  to  be  performed. 

A  formal  statement  from  a  customer  assuring  that  conformity 
is  realized  or  attainable  on  the  Ada  implementation  for 
which  validation  status  is  realized. 

A  computer  system  where  Ada  source  programs  are  transformed 
into  executable  form. 

A  test  that  contains  one  or  more  test  objectives  found  to  be 
irrelevant  for  the  given  Ada  implementation. 

International  Organization  for  Standardization. 

Software  that  controls  the  execution  of  programs  and  that 
provides  services  such  as  resource  allocation,  scheduling, 
input/output  control,  and  data  management.  Usually, 
operating  systems  are  predominantly  software,  but  partial  or 
complete  hardware  implementations  are  possible. 

A  computer  system  where  the  executable  form  of  Ada  programs 
are  executed. 


The  compiler  of  a  validated  Ada  implementation. 


An  Ada  implementation  that  has  been  validated  successfully 
either  by  AVF  testing  or  by  registration  [Pro90]. 

The  process  of  checking  the  conformity  of  an  Ada  compiler  to 
the  Ada  programming  language  and  of  issuing  a  certificate 
for  this  implementation. 

A  test  found  to  be  incorrect  and  not  used  in  conformity 
testing.  A  test  may  be  incorrect  because  it  has  an  invalid 
test  objective,  fails  to  meet  its  test  objective,  or 
contains  erroneous  or  illegal  use  of  the  Ada  programming 
language. 
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IMPLEMENTATION  DEPENDENCIES 


2.1  WITHDRAWN  TESTS 

The  following  tests  have  been  withdrawn  by  the  AVO.  The  rationale  for 
withdrawing  each  test  is  available  from  either  the  AVO  or  the  AVF.  The 
publication  date  for  this  list  of  withdrawn  tests  is  2  September  1990. 


E28005C 

B28006C 

C34006D 

B41308B 

C43004A 

C45114A 

C45346A 

C45612B 

C45651A 

C46022A 

B49008A 

A74006A 

B83022B 

B83022H 

B83025B 

B83025D 

B83026B 

B85001L 

C83026A 

C83041A 

C97116A 

C98003B 

BA2011A 

CB7001A 

CB7001B 

CB7004A 

CC1223A 

BC1226A 

CC1226B 

BC3009B 

BD1B02B 

BD1B06A 

AD1B08A 

BD2A02A 

CD2A21E 

CD2A23E 

CD2A32A 

CD2A41A 

CD2A41E 

CD2A87A 

CD2B15C 

BD3006A 

CD4022A 

CD4022D 

CD4024B 

CD4024C 

CD4024D 

CD4031A 

CD4051D 

CD5111A 

CD7004C 

ED7005D 

CD7005E 

AD7006A 

CD7006E 

AD7201A 

AD7201E 

CD7204B 

BD8002A 

BD8004C 

CD9005A 

CD9005B 

CDA201E 

CE2107I 

CE2119B 

CE2205B 

CE2405A 

CE3111C 

CE3118A 

CE3411B 

CE3412B 

CE3812A 

CE3814A 

CE3902B 

2.2  INAPPLICABLE  TESTS 

A  test  is  inapplicable  if  it  contains  test  objectives  which  are  irrelevant 
for  a  given  Ada  implementation.  Reasons  for  a  test's  inapplicability  may 
be  supported  by  documents  issued  by  the  ISO  and  the  AJPO  known  as  Ada 
Commentaries  and  commonly  referenced  in  the  format  Al-ddddd.  For  this 
implementation,  the  following  tests  were  determined  to  be  inapplicable  for 
the  reasons  indicated;  references  to  Ada  Commentaries  are  included  as 
appropriate. 


The  following  201  tests  have  floating-point  type  declarations  requiring 
more  digits  than  SYSTEM. MAX_DIGITS: 
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C24113L. 

C35706L. 

C35708L. 

C45241L. 

C45421L. 

C45524L. 

C45641L. 


Y 

(14 

tests) 

C35705L.  .Y 

(14 

tests) 

Y 

(14 

tests) 

C35707L. .Y 

(14 

tests) 

Y 

(14 

tests) 

C35802L. . Z 

(15 

tests) 

Y 

(14 

tests) 

C45321L. . Y 

(14 

tests) 

Y 

(14 

tests) 

C45521L. . Z 

(15 

tests) 

Z 

(15 

tests) 

C45621L. . Z 

(15 

tests) 

Y 

(14 

tests) 

C46012L. . Z 

(15 

tests) 

The  following  21  tests  check  for  the  predefined  type  LONG_INTEGER: 


C35404C 

C45502C 

C45612C 

B52004D 

CD7101F 


C45231C 

C45503C 

C45613C 

C55B07A 


C45304C 

C45504C 

C45614C 

B55B09C 


C45411C 

C45504F 

C45631C 

B86001W 


C45412C 

C45611C 

C45632C 

C86006C 


C35702A,  C35713B,  C45423B,  B86001T,  and  C86006H  check  for  the  predefined 
type  SHORT_FLOAT. 

C35713D  and  B86001Z  check  for  a  predefined  floating-point  type  with  a 
name  other  than  FLOAT,  LONG  FLOAT,  or  SHORT  FLOAT. 


C45531M..P  (4  tests)  and  C45532M..P  (4  tests)  check  fixed-point 
operations  for  types  that  require  a  SYSTEM. MAX_MANTISSA  of  47  or 
greater. 


C45531I..L  (4  tests)  and  C45532I..L  (4  tests)  check  fixed-point 
operations  for  types  that  require  a  SYSTEM. MAX_MANTISSA  of  31  or 
greater.  For  this  implementation  SYSTEM. MAX_MANTISSA  =.  30. 

C45624A  checks  that  the  proper  exception  is  raised  if  MACHINEOVERFLOWS 
is  FALSE  for  floating  point  types  with  digits  5.  For  this 
implementation,  MACHINE_0VERFL0WS  is  TRUE. 

C45624B  checks  that  the  proper  exception  is  raised  if  MACHINE_OVERFLOWS 
is  FALSE  for  floating  point  types  with  digits  6.  For  this 
implementation,  MACHINE_OVERFLOWS  is  TRUE. 

C86001F  recompiles  package  SYSTEM,  making  package  TEXT_I0,  and  hence 
package  REPORT,  obsolete.  For  this  implementation,  the  package  TEXT_I0 
is  dependent  upon  package  SYSTEM. 

B86001Y  checks  for  a  predefined  fixed-point  type  other  than  DURATION. 

C96005B  checks  for  values  of  type  DURATION' BASE  that  are  outside  the 
range  of  DURATION.  There  are  no  such  values  for  this  implementation. 

CD1009C  uses  a  representation  clause  specifying  a  non-default  size  for  a 
floating-point  type. 


CD2A84A,  CD2A84E,  CD2A84I..J  (2  tests),  and  CD2A840  use  representation 
clauses  specifying  non-default  sizes  for  access  types. 
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The  tests  listed  in  the  following  table  are  not  applicable  because  the 
given  file  operations  are  supported  for  the  given  combination  of  mode 
and  file  access  method. 


Test 

File  Operation  Mode 

File  Access  Method 

CE2102D 

CREATE 

IN  FILE 

SEQUENTIAL  10 

CE2102E 

CREATE 

OUT  FILE 

SEQUENTIAL  10 

CE2102F 

CREATE 

INOUT  FILE 

DIRECT  10 

CE2102I 

CREATE 

IN  FILE 

DIRECT  10 

CE2102J 

CREATE 

OUT  FILE 

DIRECT  10 

CE2102N 

OPEN 

IN  FILE 

SEQUENTIAL  10 

CE21020 

RESET 

IN  FILE 

SEQUENTIAL  10 

CE2102P 

OPEN 

OUT  FILE 

SEQUENTIAL  10 

CE2102Q 

RESET 

OUT  FILE 

SEQUENTIAL  10 

CE2102R 

OPEN 

INOUT  FILE 

DIRECT  10 

CE2102S 

RESET 

INOUT  FILE 

DIRECT  10 

CE2102T 

OPEN 

IN  FILE 

DIRECT  10 

CE2102U 

RESET 

IN  FILE 

DIRECT  10 

CE2102V 

OPEN 

OUT  FILE 

DIRECT  10 

CE2102W 

RESET 

OUT  FILE 

DIRECT  10 

CE3102E 

CREATE 

IN  FILE 

TEXT  10 

CE3102F 

RESET 

Any  Mode 

TEXT  10 

CE3102G 

DELETE 

TEXT  10 

CE3102I 

CREATE 

OUT  FILE 

TEXT  10 

CE3102J 

OPEN 

IN  FILE 

TEXT  10 

CE3102K 

OPEN 

OUT  FILE 

TEXT  10 

CE2203A  checks  that  WRITE  raises  USE_ERR0R  if  the  capacity  of  the 
external  file  is  exceeded  for  SEQUENTIALIO.  This  implementation  does 
not  restrict  file  capacity. 

CE2403A  checks  that  WRITE  raises  USE_ERR0R  if  the  capacity  of  the 
external  file  is  exceeded  for  DIRECT_IO.  This  implementation  does  not 
restrict  file  capacity. 

CE3115A  attempts  resetting  of  an  external  file  with  0UT_FILE  mode,  which 
is  not  supported  with  multiple  internal  files  associated  with  the  same 
external  file  when  they  have  different  modes. 

CE3304A  checks  that  USE_ERR0R  is  raised  if  a  call  to  SET_LINE_LENGTH  or 
SET_PAGE_LENGTH  specifies  a  value  that  is  inappropriate  for  the  external 
file.  This  imp] ementation  does  not  have  inappropriate  values  for  either 
line  length  or  page  length. 

CE3413B  checks  that  PAGE  raises  LAY0UT_ERR0R  when  the  value  of  the  page 
number  exceeds  COUNT'LAST.  For  this  implementation,  the  value  of 
COUNT' LAST  is  greater  than  150000  making  the  checking  of  this  objective 
impractical. 


2-3 


IMPLEMENTATION  DEPENDENCIES 


2.3  TEST  MODIFICATIONS 

Modifications  (see  section  1.3)  were  required  for  16  tests. 

The  following  tests  were  split  into  two  or  more  tests  because  this 
implementation  did  not  report  the  violations  of  the  Ada  Standard  in  the  way 
expected  by  the  original  tests. 

B24009A  B33301B  B38003A  B38003B  B38009A  B38009B 

B65008G  B85008H  B91001H  BC1303F  BC3005B  BD2B03A 

BD2D03A  BD4003A  BD8004C 


CE3804H  requires  that  string  "-3.525"  can  be  read  from  a  file  using 
FLOAT  10  and  that  it  equal  the  numeric  literal  "-3.525";  however,  because 
-3.525  is  not  a  model  number  this  equality  need  not  hold.  This 
implementation  reports  FAILED  and  prints  (only)  the  Report . Failed  message 
from  line  116,  "WIDTH  CHARACTERS  NOT  READ";  the  AVO  ruled  that  the  test  be 
graded  as  passed  by  Evaluation  Modification. 
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PROCESSING  INFORMATION 


3.1  TESTING  ENVIRONMENT 

The  Ada  implementation  tested  in  this  validation  effort  is  described 
adequately  by  the  information  given  in  the  initial  pages  of  this  report. 

For  a  point  of  contact  for  technical  information  about  this  Ada 
implementation  system,  see: 

Jeff  Hollensen 

Harris  Corporation,  Computer  Systems  Division 
2101  V.  Cypress  Creek  Rd. 

Ft.  Lauderdale  FL  33309 

For  a  point  of  ontact  for  sales  information  about  this  Ada  implementation 
system,  see: 


Harris  Computer  Systems  Division 
Marketing  Communication 
(305)  973-5124 


Testing  of  this  Ada  implementation  was  conducted  at  the  customer's  site  by 
a  validation  team  from  the  AVF. 


3.2  SUMMARY  OF  TEST  RESULTS 

An  Ada  Implementation  passes  a  given  ACVC  version  if  it  processes  each  test 
of  the  customized  test  suite  in  accordance  with  the  Ada  Programming 
Language  Standard,  whether  the  test  is  applicable  or  inapplicable; 
otherwise,  the  Ada  Implementation  fails  the  ACVC  [Pro90]. 

For  all  processed  tests  'inapplicable  and  applicable),  a  result  was 
obtained  that  conforms  to  the  Ada  Programming  Language  Standard. 
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a)  Total  Number  of  Applicable  Tests  3814 

b)  Total  Number  of  Withdrawn  Tests  74 

c)  Processed  Inapplicable  Tests  81 

d)  Non-Processed  I/O  Tests  0 

e)  Non-Processed  Floating-Point 

Precision  Tests  201 

f)  Total  Number  of  Inapplicable  Tests  282 


g)  Total  Number  of  Tests  for  ACVC  1.11  4170 


All  I/O  tests  of  the  test  suite  were  processed  because  this  implementation 
supports  a  file  system.  The  above  number  of  floating-point  tests  were  not 
processed  because  they  used  floating-point  precision  exceeding  that 
supported  by  the  implementation.  When  this  compiler  was  tested,  the  tests 
listed  in  section  2.1  had  been  withdrawn  because  of  test  errors. 


3 . 3  TEST  EXECUTION 

Version  1.11  of  the  ACVC  comprises  4170  tests.  When  this  compiler  was 
tested,  the  tests  listed  in  section  2.1  had  been  withdrawn  because  of  test 
errors.  The  AVF  determined  that  282  tests  were  inapplicable  to  this 
implementation.  All  inapplicable  tests  were  processed  during  validation 
testing  except  for  201  executable  tests  that  use  floating-point  precision 
exceeding  that  supported  by  the  implementation  In  addition,  the  modified 
tests  mentioned  in  section  2.3  were  also  processed. 

A  magnetic  tape  containing  the  customized  test  suite  (see  section  1.3)  was 
taken  on-site  by  the  validation  team  for  processing.  The  contents  of  the 
magnetic  tape  were  loaded  directly  onto  the  host  computer. 


After  the  test  files  were  loaded  onto  the  host  computer,  the  full  set  of 
tests  was  processed  by  the  Ada  implementation. 


Testing  was  performed  using  command  scripts  provided  by  the  customer  and 
reviewed  by  the  validation  team.  See  Appendix  B  for  a  complete  listing  of 
the  processing  options  for  this  implementation.  It  also  indicates  the 
default  options.  The  options  invoked  explicitly  for  validation  testing 
during  this  test  were: 

Option  |  Setting  Effect 

-el  If  warning  or  errors  occur  during 

compilation,  generate  a  full  source 
listing  with  the  warning/error 
messages  included  in  the  listing. 
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-v  Suppress  compilation  warning  messages. 

-L  Generate  a  full  source  listing  even 

if  no  errors  or  warnings  occurred 
during  compilation. 

-Df  This  option  causes  file  name  paths 

in  error  listings  to  only  include  the 
file  portion  of  the  path  name, 
instead  of  the  entire  root  directory 
<e.g.:  bc3205d.a,  instead  of: 
/usr2/ada/acvc/l . Il/prevals/bc/bc3205d.a) . 


Test  output,  compiler  and  linker  listings,  and  job  logs  were  captured  on 
magnetic  tape  and  archived  at  the  AVF.  The  listings  examined  on-site  by 
the  validation  team  were  also  archived. 
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MACRO  PARAMETERS 


This  appendix  contains  the  macro  parameters  used  for  customizing  the  ACVC. 
The  meaning  and  purpose  of  these  parameters  are  explained  in  [UG89].  The 
parameter  values  are  presented  in  two  tables.  The  first  table  lists  the 
values  that  are  defined  in  terms  of  the  maximum  input-line  length,  which  is 
the  value  for  $MAX_IN_LEN — also  listed  here.  These  values  are  expressed 
here  as  Ada  string  aggregates,  where  "V"  represents  the  maximum  input-line 
length. 

Macro  Parameter  Macro  Value 


$BIG_ID1  (1..V-1  =>  'A',  V  =>  '1') 

$BIG_ID2  (1..V-1  =>  'A',  V  =>  '!') 

$BIG_ID3  (1..V/2  =>  'A')  &  '3'  & 

(1 . . V-l-V/2  =>  'A') 

$BIG_ID4  (1..V/2  =>  'A')  &  '4'  & 

(1.. V-l-V/2  =>  'A') 

$BIG_INT_LIT  (1..V-3  =>  '0')  &  "298" 

SBIGREALLIT  (1..V-5  =>  '0')  &  "690.0" 

SBIGSTRINGl  &  (1..V/2  =>  'A' )  & 

$BIG_STRING2  &  (1.. V-l-V/2  =>  'A')  &  '1'  & 

SBLANKS  (1. .V-20  =>  '  ' ) 

$MAX_LEN_INT_BASED_LITERAL 

"2:"  &  (1..V-5  =>  '0')  &  "11:" 

$MAX_LEN_REAL_BASED_LITERAL 

"16:"  &  (1..V-7  =>  '0')  &  "F.E: " 

$MAX_STRING_LITERAL  ' "'  &  (1..V-2  =>  'A')  & 
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The  following  table  lists  all  of  the  other  macro  parameters  and  their 
respective  values. 


Macro  Parameter 

Macro  Value 

$MAX_IN_LEN 

499 

$ACC_SIZE 

32 

SALIGNMENT 

8 

$COUNT_LAST 

2147483647 

$DEFAULT_MEM_SIZE 

3221225469 

$DEFAULT_STOR_UNIT 

8 

$DEFAULT_SYS_NAME 

HARRIS_GCX 

SDELTADOC 

2 .0**(-30) 

SENTRYADDRESS 

SYSTEM . PHYSICAL_ADDRESS ( 16 ) 

$  ENTR Y_ ADDRE  SSI 

SYSTEM. PHYSICAL_ADDRESS( 17 ) 

$  ENTR Y_ADDRE  S  S  2 

SYSTEM . PHYSICAL_ADDRESS ( 18 ) 

$FIELD_LAST 

2147483647 

$FILE_TERMINATOR 

t  t 

$FIXED_NAME 

NO_SUCH_FIXED_TYPE 

$FLOAT_NAME 

NO_SUCH_FLOAT_TYPE 

$FORM_STRING 

ft  ft 

$FORM_STRING2 

"CANNOT_RESTRICT_FILE_CAPACITY' 

SGREATER  THAN  DURATION 

100000.0 

SGREATER  THAN  DURATION  BASE  LAST 

10000000.0 

$GREATER_THAN_FLOAT_BASE  LAST 

3 . 5E+38 

$GREATER_THAN_FLOAT_SAFE_LARGE 

1.0E38 
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$GR2ATER_THAN_SH0RT_FL0AT_SAFE_LARGE 

1.0E308 

$HIGH_PRIORITY  9 

$ I LLEGAL_EXTERNAL_FI LE_NAME 1 

/no/such/ file/name 

$ I LLEG AL_EXTERNAL_FI LE_NAME  2 

/this/ file/does/not /exist 

$INAPPROPRIATE_LINE_LENGTH 

-1 

$INAPPROPRIATE_PAGE_LENGTH 

-1 

$INCLUDE_PRAGMA1  PRAGMA  INCLUDE ( "A28006D1 .TST" ) 

$INCLUDE_PRAGMA2  PRAGMA  INCLUDE( "B28006D1 .TST" ) 

$INTEGER_FIRST  -2147483648 

$ INTEGER_LAST  2147483647 

$INTEGER_LAST_PLUS_1  2147482648 

$ I NTERF ACE_  LANG  UAGE  C 

$  LE  S  S_THAN_DURATI ON  -100000.0 

$LESS_THAN_DURATION_BASE_FIRST 

-10000000.0 

$LINE_TERMINATOR  ASCII. LF 

SLOWPRIORITY  0 

$MACHINE_CODE_STATEMENT 

code_l' (clr_b,dO) ; 

$MACHINE_CODE_TYPE  operand 

$MANTISSA_DOC  30 

$MAX_DIGITS  15 

$MAX_INT  2147483647 

$MAX_INT_PLUS_1  2147483648 


$MIN  I NT 


-2147483648 


MACRO  PARAMETERS 


$NAME  TINY_INTEGER 

$NAME_LIST  HARRIS_GCX 

$NAME_SPECIFICATIONl 

/gxld9/ada/acvc/l. ll/preval_gex_l . ll/SRC/ce/X2120A 
$NAME_SPECIFICATION2 

/gxld9/ada/acvc/l. ll/preval_gcx_l. ll/SRC/ce/X2120B 
$NAME_SPECIFICATION3 

/gxld9/ada/acvc/l . ll/preval_gcx_l . ll/SRC/ce/X3119A 
$NEG_BASED_INT  16#F000000E# 

$NEV_MEM_SIZE  3221225469 

$NEW_STOR_UNIT  8 

$NEW_S Y  S_NAME  HARRIS_GCX 

$PAGE_TERMINATOR  ASCII. LF  &  ASCII. FF 

$RECORD_DEFINITION 

type  code_l(op:opcode)  is  record  oprnd_l:  operand;  end  record; 
SRECORDNAME  codel 

$TASK_SIZE  32 

$TASK_STORAGE_SIZE  10240 

STICK  0.01 

SVARIABLEADDRESS  FCNDECL. SPACE( 1024) 

$VARIABLE_ADDRESS1  FCNDECL. SPACE ( 1024) 

$VARIABLE_ADDRESS2  FCNDECL. SPACE( 1024) 

$YOUR_PRAGMA  EXTERNAL_NAME 
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COMPILATION  SYSTEM  OPTIONS 


The  compiler  and  linker  options  of  this  Ada  implementation,  as  described  in 
this  Appendix,  are  provided  by  the  customer.  Unless  specifically  noted 
otherwise,  references  in  this  appendix  are  to  compiler  documentation  and 
not  to  this  report. 


Harris  Ada  Compiler  and  Link  Options 


Usage:  ada  [opt 

ions]  ada  source. a 

...  [a. Id  options]  [object  file.o] 

Options: 

t-bl 

(object) 

Symbolic  object  listing  to  stdout 

l-dl 

(dependencies) 

Only  check  for  dependencies 

[-dr] 

(data  record) 

Allow  variables  to  be  "data  recorded" 

t-e] 

(errors) 

List  syntax  errors  to  stdout 

[-eh] 

(errors  hed) 

Errors  to  source,  call  hed 

[-el] 

(errors  list) 

Errors  &  source  to  stdout 

[-ev] 

(errors  vi) 

Errors  to  source,  call  vi 

l-m] 

(map) 

Print  an  object  map  (only  with  -M  option) 

[-0  name] 

(output) 

Name  the  executable  program 

l-p] 

(profiling) 

Profiling,  instrument  code  for  a.prof(l) 

[-pp  "options"] 

(preprocess) 

Pass  options  to  a.pp 

[-u] 

(update) 

Force  update  of  ada  library 

l-v] 

(verbose) 

Print  info  about  the  compile 

[-V] 

(warnings) 

Suppress  warnings 

t-Df] 

File  name  paths  only  include 

[ -E[ 1 ]  [name]] 

(errors) 

file  portion  of  the  path  name, 
Errors/source  to  stdout  and  file 

[-G] 

(call  graph) 

Profiling,  instrument  code  for  a.gprof(l) 

l  -H  ] 

(help) 

Print  this  description  and  stop 

[-K] 

(keep) 

Keep  the  IL  file  after  compile 

[-L] 

(list) 

Generate  a  source  listing  to  stdout 

[ -M  [unit]. a]] 

(main) 

Call  a. Id  to  create  a  program 

( -N] 

(not  shared) 

Set  default  of  pragma  SHARE  BODY  to  FALSE 

[-0[level]  ] 

(optimize) 

Select  level  of  code  optimization  (0-3) 

[ -R  [library]] 

(recompile) 

Force  updating  of  instantiations 

[-S] 

(suppress) 

Apply  pragma  suppress 

[-T] 

(timings) 

Print  wall  and  CPU  times,  memory  usage 
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Usage:  a. Id  [options]  unit  name  [Id  options | arguments] 


Options: 

[-0  exec  file] 

(output) 

[  -m  ] 

(map) 

[-shmem  params] 

(shared  memory) 

[-V] 

(verbose) 

[-V] 

(warnings) 

[-F] 

(files) 

[-H] 

(help) 

[-0] 

(quiet) 

[-U] 

(uni ts) 

[-V] 

(verify) 

Name  the  generated  program  exec_file, 
instead  of  the  default  name,  a. out. 
Print  out  an  object  map. 

The  quoted  params  string  contains  a  set 
of  shared_package  shared  memory  config. 
parameters. 

Print  the  link  stream  before  execution. 
Suppress  warning  messages. 

List  dependent  files,  suppressing 
execution. 

Print  this  description  and  stop. 

Inhibit  terminal  status  line  messages. 
List  dependent  units,  suppressing 
execution. 

Print  the  link  stream,  suppressing 
execution. 
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APPENDIX  F  OF  THE  Ada  STANDARD 


The  only  allowed  implementation  dependencies  correspond  to 
implementation-dependent  pragmas,  to  certain  machine-dependent  conventions 
as  mentioned  in  Chapter  13  of  the  -da  Standard,  and  to  certain  allowed 
restrictions  on  representation  clauses.  The  implementation-dependent 
characteristics  of  this  Ada  implementation,  as  described  in  this  Appendix, 
are  provided  by  the  customer.  Unless  specifically  noted  otherwise, 
references  in  this  Appendix  are  to  compiler  documentation  and  not  to  this 
report.  Implementation-specific  portions  of  the  package  STANDARD,  which 
are  not  a  part  of  Appendix  F,  are: 


package  STANDARD  is 


type  INTEGER  is  range  -2_147_483  648  ..  2_147_483_647  ; 
type  SHORTINTEGER  is  range  -32_768  ..  32_767  ; 
type  TINY_INTEGER  is  range  -128  ..  127  ; 

type  FLOAT  is  digits  6  range  -1.70141E+38  . . 1 . 70141E+38  ; 
type  LONG_FLOAT  is  digits  15  range  -1 . 79769313486232E+308 

..  1 . 79769313486232E+308  ; 

type  DURATION  is  delta  2.0**(-13)  range  -131_072.0  ..  131_072.0  ; 


end  STANDARD; 
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Appendix  F  of  the  Ada  Language  Reference  Manual 


Harris  Ada  v5.1  (ACVC  1.11,  Host  and  Target  =  Harris  NH-3800) 


PROGRAM  STRUCTURE  AND  COMPILATION 

A  "main"  program  must  be  a  non-generic  subprogram  that  is  either  a 
procedure  or  a  function  returning  an  Ada  STANDARD . INTEGER  (the  predefined 
type).  A  "main"  program  cannot  be  a  generic  subprogram  or  an  instantiation 
of  a  generic  subprogram. 

PRAGMAS 

Implementation-Dependent  Pragmas 

Pragma  CONTROLLED  is  recognized  by  the  implementation  but  does  not  have  an 
effect  in  this  release. 

Pragma  ELABORATE  is  implemented  as  described  in  Appendix  B  of  the  Ada  RM. 

Pragma  INLINE  is  implemented  as  described  in  section  6.3.2  and  Appendix  B 
of  the  Ada  RM.  See  section  2.17  of  this  manual  for  more  details. 

Pragma  INTERFACE  is  recognized  by  the  implementation  and  support  calls  to  C 
and  FORTRAN  language  functions.  The  Ada  specifications  can  be  either 
functions  or  procedures.  All  parameters  must  have  mode  IN. 

For  C,  the  types  of  parameters  and  the  result  type  for  functions  must  be 
scalar,  access,  or  the  predefined  type  ADDRESS  defined  in  the  package 
SYSTEM.  Record  and  array  objects  can  be  passed  by  reference  using  the 
ADDRESS  attribute.  The  default  link  name  is  the  symbolic  representation  of 
the  simple  name  converted  to  lowercase.  The  link  name  of  interface 
routines  can  be  changed  via  the  implementation-defined  pragma 
externalname. 

For  FORTRAN,  all  parameters  are  passed  by  reference.  The  parameter  types 
must  have  the  type  ADDRESS  defined  in  the  package  SYSTEM.  The  result  type 
for  a  FORTRAN  function  must  be  a  scalar  type.  Care  should  be  taken  when 
using  tasking  and  FORTRAN  functions.  Since  FORTRAN  is  not  reentrant,  it  is 
recommended  that  an  Ada  controller  task  be  used  to  access  FORTRAN 
functions.  The  default  link  name  is  the  symbolic  representation  of  the 
simple  name  converted  to  lowercase,  with  a  leading  and  trailing  underscore 
("_")  character.  The  link  name  of  interface  routines  can  be  changed  via 
the  implementation-defined  pragma  external_name . 

For  FORTRAN,  the  implementation  also  detects  usage  of  this  pragma  at  link 
time  see  (a. Id)  and  includes  a  call  to  the  system  supplied  FORTRAN 
initialization  routine  as  part  of  the  elaboration  of  the  Ada  program. 
Additionally,  the  default  system  FORTRAN  libraries  are  included  in  the 
linking  of  the  Ada  program. 
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Pragma  LIST  is  implemented  as  described  in  Anpendix  B  of  the  Ada  RM. 

Pragma  MEMORY_SIZE  is  recognized  by  the  implementation  but  has  no  visible 
effect.  The  implementation  restricts  the  argument  to  the  predefined  value 
in  the  package  system. 

Pragma  OPTIMIZE  is  recognized  by  the  implementation  but  has  no  effect  in 
this  release.  See  the  -0  option  for  ada  for  code  optimization  options,  or 
the  implementation  defined  pragma,  0PT_LEVEL. 

Pragma  PACK  causes  the  compiler  to  choose  a  non-aligned  representation  for 
elements  of  composite  types.  Application  of  the  pragma  will  cause  objects 
to  be  packed  to  the  bit  level. 

Pragma  PAGE  is  implemented  as  described  in  Appendix  B  of  the  Ada  RM. 

Pragma  PRIORITY  is  implemented  as  described  in  Appendix  B  of  the  Ada  RM. 
Priorities  range  from  0  to  9,  with  9  being  the  most  urgent. 

Pragma  SHARED  is  recognized  by  the  implementation  but  has  no  effect. 

Pragma  STORAGE_UNIT  is  recognized  by  the  implementation  but  has  no  visible 
effect.  The  implementation  restricts  the  argument  to  the  predefined  value 
in  the  package  system. 

Pragma  SUPPRESS  in  the  single  parameter  form  is  supported  and  applies  from 
the  point  of  occurrence  to  the  end  of  the  innermost  enclosing  block. 
DIVISION  CHECK  and  0VERFL0V_CHECK  for  floating  point  types  will  reduce  the 
amount  oT  overhead  associated  with  checking,  but  is  not  fully  repressable. 
The  double  parameter  form  of  the  pragma,  with  a  name  of  an  object,  type,  or 
subtype  is  recognized,  but  has  no  effect. 

Pragma  SYSTEM  NAME  is  recognized  by  the  implementation  but  has  no  visible 
effect.  The  Implementation  provides  only  one  enumeration  value  for 
SYSTEMNAME  in  the  package  SYSTEM. 

Implementation-Defined  Pragmas 

Pragma  EXTERNAL_NAME  provides  a  method  for  specifying  an  alternative  link 
name  for  variables,  functions  and  procedures.  The  required  parameters  are 
the  simple  name  of  the  object  and  a  string  constant  representing  the  link 
name.  An  underscore  is  automatically  prepended  to  the  specified  name, 
unless  the  first  character  of  the  name  is  an  underscore.  Note  that  this 
pragma  is  useful  for  referencing  functions  and  procedures  that  have  had 
pragma  INTERFACE  applied  to  them,  in  such  cases  where  the  functions  or 
procedures  have  link  names  that  do  not  conform  to  Ada  identifiers.  The 
pragma  must  occur  after  any  such  applications  of  pragma  INTERFACE  and 
within  the  same  declarative  part  or  package  specification  that  contains  the 
object . 

Pragma  INTERFACE_OBJECT  provides  an  interface  to  objects  defined  externally 
from  the  Ada  compilation  model,  or  an  object  defined  in  a  foreign  language. 
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For  example,  a  variable  defined  in  the  run-time  system  may  be  accessed  via 
the  pragma.  This  pragma  has  two  required  parameters,  the  first  being  the 
simple  name  of  an  Ada  variable  to  be  associated  with  the  foreign  object. 

The  second  parameter  is  a  string  constant  that  defines  the  link  name  of  the 
object.  The  variable  declaration  must  occur  before  the  pragma  and  both 
must  occur  within  the  same  declarative  part  or  package  specification. 

Pragma  INTERFACE_SHARED_OBJECT  provides  an  interface  to  objects  defined  in 
foreign  languages  which  exist  in  CX/UX  shared  memory  segments. 

Specifically,  this  allows  for  the  sharing  of  data  between  Ada  objects  and 
FORTRAN  or  C  objects  defined  within  the  sair.o  process  or  in  a  separate 
process . 

Pragma  INTERFACE_SHARED_OBJECT  associates  an  Ada  variable  with  a  CX/UX 
shared  memory  segment.  It  has  two  required  parameters.  The  first 
parameter  is  the  simple  name  of  the  Ada  variable  to  be  associated  with  the 
foreign  object.  The  second  parameter  is  a  string  constant  that  defines  the 
external  link  name  of  the  object  as  defined  in  the  foreign  language.  The 
variable  declaration  must  occur  before  the  pragma  and  both  must  occur 
within  the  same  declarative  part  or  package  specification. 

Variables  marked  with  the  pragma  must  have  a  static  size.  It  is 
recommended  that  an  explicit  length  clause  be  specified  for  composite 
objects  to  ensure  conformance  with  the  size  as  defined  by  the  foreign 
language.  Additionally,  record  representation  clauses  may  be  used  to 
define  the  layout  of  records  to  match  the  forei  .  ^nguage  definitions. 

The  association  of  the  shared  memory  segment  to  the  Ada  variable  is 
effected  at  program  startup  time,  by  the  HAPSE  run-time  system.  However, 
specific  control  over  the  configuration  of  the  shared  memory  is  defined 
externally  from  the  Ada  compilation  model  and  requires  user  intervention. 
The  CX/UX  shmdefine  utility  has  been  provided  to  aid  the  user  in  defining 
the  configuration  of  shared  memory  segments.  The  utility  produces  a 
link-ready  file  and  a  loader  command  file  which  must  be  included  in  the 
link  of  any  Ada  program  using  pragma  INTERFACE_SHARED_OBJECT .  To  include 
these  files  in  the  link  process,  the  user  should  invoke  the  HAPSE 
prelinker,  a. Id  ,  adding  the  names  of  these  files  to  the  end  of  the  command 
line.  See  section  11.2.2  for  an  example  application  of  the  pragma.  Refer 
to  the  CX/UX  User's  Reference  Manual  for  details  on  the  shmdefine  utility. 

Pragma  LINK_OPTION  allows  a  command  to  the  linker  ld(l)  to  be  specified  in 
an  Ada  compilation  unit.  The  pragma  has  one  required  parameter,  a  string 
within  quotes  containing  the  command  to  be  passed  to  Id.  The  string 
specified  will  be  passed  directly  to  Id  by  the  a. Id  tool.  For  example,  if 
a  compilation  unit  references  the  CX/UX  curses  library,  the  pragma: 

pragma  LINK_OPTION("-lcurses") ; 

can  be  used  in  the  compilation  unit  to  link  the  CX/UX  curses  library  with 
the  resulting  Ada  program.  An  example  usage  of  this  pragma  may  be  found  in 
the  HAPSE  harrislib  library's  MATH  package.  The  body  of  this  package 
contains  a  LINK_OPTION  pragma  that  causes  all  programs  that  "with"  package 
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MATH  to  be  automatically  linked  with  the  CX/UX  math  library. 

Pragma  SHARED_PACKAGE  provides  for  the  sharing  and  communication  of  library 
level  packages.  All  variables  declared  in  a  package  marked  pragma 
SHARED_PACKAGE  (henceforth  referred  to  as  a  shared  package)  are  allocated 
in  shared  memory  that  is  created  and  maintained  by  the  implementation.  The 
pragma  can  only  be  applied  to  library  level  package  specifications.  Each 
package  specification  nested  in  a  shared  package  will  also  be  shared  and 
all  objects  declared  in  the  nested  packages  reside  in  the  same  shared 
memory  as  the  outer  package. 

The  implementation  restricts  the  kinds  of  objects  that  can  be  declared  in  a 
shared  package.  Unconstrained  or  dynamically  sized  objects  cannot  be 
declared  in  a  shared  package;  access  type  objects  cannot  be  declared  in  a 
shared  package;  and  explicit  initialization  of  objects  cannot  occur  in  a 
shared  package.  If  any  of  these  restrictions  are  violated,  a  warning 
message  is  issued  and  the  package  is  not  shared.  These  restrictions  apply 
to  nested  packages  as  well.  Note  that  if  a  nested  package  violates  one  of 
the  above  restrictions,  it  prevents  the  sharing  of  all  enclosing  packages 
as  well.  It  is  also  important  to  note  that  some  objects  can  be  implicitly 
initialized  by  the  compiler.  Declarations  of  these  objects  will  also  cause 
a  warning  message  to  be  issued,  and  will  prevent  sharing  of  the  package. 
Records  with  gaps  and  arrays  with  gaps  are  examples  of  objects  that  can  be 
implicitly  initialized. 

Task  objects  are  allowed  within  shared  packages,  however,  the  tasks  as  well 
as  the  data  defined  within  those  tasks  are  not  shared. 

Pragma  SHARED_PACKAGE  accepts  as  an  optional  argument,  "params",  that,  if 
specified,  must  be  a  string  constant  containing  a  comma  separated  list  of 
CX/UX  shared  segment  configuration  parameters,  as  defined  by  the  following: 

key=  name,  which  identifies  the  CX/UX  shared  segment  key  to  be  used  in 
subsequent  shmget  system  calls,  which  are  done  automatically  by  the 
implementation  in  configuring  the  shared  segment,  name  is  considered 
to  be  a  CX/UX  filename  which  will  be  translated  to  a  shared  segment 
key  using  the  CX/UX  ftok(3C)  service.  By  default,  HAPSE  applies  "key= 
{absolute  HAPSE  library  path}/.shmem/package_name  to  the  shared 
package.  Note  that  relative  path  names  may  be  specified  and  would 
cause  key  translation  to  be  dependent  on  the  user's  current  working 
directory  when  program  execution  is  initiated.  If  name  is  a  decimal 
integer  literal,  HAPSE  interprets  this  as  the  actual  CX/UX  key,  and 
does  not  translate  it  using  the  ftok  service. 

ipc=  (IPC_CREAT,  IPC_EXCL,  IPC_PRIVATE) ,  which  allows  the  user  to 
specify  details  about  the  initialization  of  the  shared  segment.  By 
default,  HAPSE  applies  ipc=  (IPC_CREAT)  to  the  shared  package,  thereby 
creating  the  shared  segment  if  it  did  not  previously  exist.  If  any 
ipc  parameters  are  given,  they  entirely  replace  the  default  ipc 
specification. 

SHM_RDONLY,  which  specifies  that  the  segment  is  only  available  for 
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READ  operations.  HAPSE  defaults  shared  package  segments  to 
READ/VRITE.  CAUTION:  Use  of  the  'LOCK  or  'UNLOCK  attributes  with  a 
SHM_RDONLY  shared  memory  segment  will  raise  PROGRAM_ERROR  at  runtime. 

mode  =  n,  where  n  is  assumed  to  be  a  3  digit  octal  number  defining  the 
access  to  the  shared  segment.  By  default,  HAPSE  applies  mode=644  to 
the  shared  package,  (owner  read/write,  group  read,  other  read). 

SHM_L0CAL,  which  requests  that  pages  for  the  shared  segment  be 
allocated  from  the  local  memory  pool  (GCX  only).  If  a  program 
attempts  to  attach  to  a  segment  which  has  been  allocated  from  local 
memory  on  a  different  CPU,  then  the  attachment  will  fail.  See 
shmget(2) . 

SHM_HARD,  which  when  used  in  conjunction  with  SHM_L0CAL,  specifies 
that  pages  for  the  shared  segment  MUST  be  allocated  from  the  local 
memory  pool  (GCX  only).  If  pages  are  not  available  from  local  memory 
then  the  signal  SIGSEGV  is  delivered  to  the  process.  See  shmget(2). 

SHMIO,  which  specifies  that  the  segment  will  be  bound  to  I/O  memory. 
See  shmget(2). 

bind=n,  where  n  is  assumed  to  be  an  octal  number.  The  segment  will  be 
attached  to  the  physical  memory  address  specified  by  n.  Root  user 
access  is  required  for  this  operation.  WARNING:  If  the  shmbind(2) 
attempt  fails  due  to  EBUSY  or  EREGSTALE,  the  implementation  will 
ignore  the  error  and  continue,  assuming  that  another  program  has 
already  bound  the  segment  to  the  desired  location.  Shared  memory 
segments  bound  to  physical  memory  should  be  freed  manually  by  the  user 
via  ipcrm(l). 

nobsem,  which  prohibits  the  use  of  shared  package  lock  attributes 
('LOCK  and  'UNLOCK).  In  shared  packages  marked  with  this  parameter, 
no  binary  semaphore  space  is  initialized  in  the  shared  memory  segment. 
Any  attempt  to  invoke  the  lock  attributes  in  a  shared  package  marked 
with  this  parameter,  will  result  in  PROGRAMERROR  being  raised. 

Unlike  SHMRDONLY  shared  packages,  "no_bsem"  packages  have  READ/WRITE 
capability. 


Caution:  By  default,  every  shared  package  that  is  available  for  READ/URITE 
has  a  binary  semaphore  initialized  which  occupies  the  last  12  bytes  of  the 
segment.  If  a  shared  package  is  bound  to  a  device  using  the  bind= 
parameter,  be  aware  that  the  contents  of  these  12  bytes  may  change  during 
package  elaboration  and  in  the  presence  of  'LOCK  and  'UNLOCK  attribute 
usage.  The  initialization  of  this  binary  semaphore  can  be  suppressed  if 
SHM_RDONLY  or  no  bsem  is  applied  to  the  shared  package.  In  this  case, 
references  to  'LOCK  or  'UNLOCK  will  result  in  PR0GRAM_ERR0R  being  raised. 

A  detailed  explanation  of  the  IPC  and  SHM  flags,  and  access  modes  may  be 
found  in  the  CX/UX  Programmer's  Reference  Manual,  Chapter  2. 
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The  pragma  must  appear  within  the  specification  of  the  library  level 
package.  The  pragma  may  also  be  repeated  in  the  package  body  to  allow  the 
user  to  override  the  shared  memory  configuration  parameters  that  were 
associated  with  the  pragma  in  the  specification.  Additionally,  these 
configuration  parameters,  as  defined  above,  may  also  be  specified  at  link 
time  to  a. Id,  via  the  -shmem  "params"  option,  where  "params"  is  defined  as 
above  with  the  addition  that  the  first  item  in  the  list  must  be  the  name  of 
a  shared  package.  If  this  option  is  used,  then  it  replaces  all  previous 
information  that  may  have  been  provided  with  all  pragmas  for  that  package. 

With  the  valid  application  of  pragma  SHARED_PACKAGE  to  a  library  level 
package,  the  following  assumptions  can  be  made  about  the  objects  declared 
in  the  package: 

The  lifetime  of  such  objects  is  greater  than  the  lifetime  defined  by 
the  complete  execution  of  a  single  program. 

The  lifetime  of  such  objects  is  guaranteed  to  extend  from  the 
elaboration  of  the  shared  package  by  the  first  concurrent  program 
until  the  termination  of  execution  of  the  last  concurrent  program. 


In  the  assumptions  above,  a  concurrent  program  is  defined  to  be  any  Ada 
program  which  elaborates  the  body  of  a  shared  package,  whose  span  of 
execution,  from  elaboration  of  such  a  package  to  termination,  overlaps  that 
of  another  such  program. 

In  actuality,  the  shared  memory  segments  created  by  these  programs  remain 
even  after  the  last  concurrent  program  has  exited.  The  values  of  objects 
within  these  segments  remains  valid  until  the  segment  is  destroyed,  or 
until  the  system  is  rebooted.  Segments  may  be  explicitly  removed  through 
the  shared  memory  service  shmctl,  to  which  an  interface  is  provided  in  the 
HAPSE  package  sharedmemorysupport .  Alternatively,  the  user  may  obtain 
information  about  active  shared  memory  segments  through  the  CX/UX  utility 
ipcs(3).  These  segments  may  be  removed  via  the  CX/UX  utility  iprm(l). 

Programs  that  attempt  to  reference  the  contents  of  objects  declared  in 
shared  packages  that  have  not  been  implicitly  or  explicitly  initialized  are 
technically  erroneous  as  defined  by  the  RM  (3.2.1(18)).  This 
implementation,  however,  does  not  prevent  such  references  and,  in  fact 
expects  them. 

The  above  discussion  describes  the  intent  that  several  Ada  programs  may 
begin,  continue,  and  complete  their  execution  simultaneously,  with  the 
contents  of  the  variables  in  the  shared  packages  consistent  with  the 
execution  of  those  programs. 

Since  packages  that  contain  objects  that  are  initialized  are  not  candidates 
for  pragma  SHARED_PACKAGE,  the  implementation  suggests  that  programs  be 
created  for  the  sole  purpose  of  initializing  objects  in  the  shared  package. 

The  association  of  a  CX/UX  shared  memory  segment  with  the  shared  package  is 
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effected  during  the  elaboration  of  the  package  body.  If  this  association 
should  fail  due  to  system  shared  memory  constraints,  access,  or  improper 
use  of  shared  memory  configuration  parameters,  one  of  several  predefined 
exceptions  will  be  raised.  The  exceptions  are  of  the  form: 

shared_package_error. {name  of  package} . {service} . {code} 

where  .{code}  is  a  CX/UX  error  code  mnemonic. 

For  example,  shared_package_error. package. shmat.EMFILE  would  be  raised  to 
indicate  that  the  shared  package  attachment  failed  because  it  would  exceed 
the  system  imposed  limit  on  active  shared  segments.  These  exceptions  are 
not  available  to  the  user  since  exceptions  generated  from  the  elaboration 
of  library  level  package  bodies  have  no  enclosing  scope  from  which  to 
supply  a  handler.  Refer  to  the  CX/UX  Programmer's  Reference  Manual  for  a 
detailed  list  of  the  error  conditions  for  shmget(2)  and  shmop(2). 

So  that  programs  can  define  critical  sections  to  reference  and  update 
variables  within  the  shared  packages,  HAPSE  has  provided  semaphore 
operations.  See  the  description  of  the  implementation-defined  attributes 
P ' LOCK  and  P' UNLOCK. 

Pragma  SHAREBODY  is  used  to  indicate  whether  or  not  an  instantiation  is  to 
be  shared.  The  pragma  may  reference  the  generic  unit  or  the  instantiated 
unit.  When  it  references  a  generic  unit,  it  sets  sharing  on/off  for  all 
instantiations  of  the  generic,  unless  overridden  by  specific  SHAREBODY 
pragmas  for  individual  instantiations.  When  it  references  an  instantiated 
unit,  sharing  is  on/off  only  for  that  unit.  The  default  is  to  share  all 
generics  that  can  be  shared,  unless  the  unit  uses  pragma  INLINE. 

Pragma  SHAREBODY  is  only  allowed  in  the  following  places:  immediately 
within  a  declarative  part,  immediately  within  a  package  specification,  or 
after  a  library  unit  in  a  compilation,  but  before  any  subsequent 
compilation  unit.  The  form  of  this  pragma  is 

pragma  SHAREBODY  (generic_name,  booleanliteral) 

Note  that  a  parent  instantiation  is  independent  of  any  individual 
instantiation,  therefore  recompilation  of  a  generic  with  different 
parameters  has  no  effect  on  other  compilations  that  reference  it.  The  unit 
that  caused  compilation  of  a  parent  instantiation  need  not  be  referenced  in 
any  way  by  subsequent  units  that  share  the  parent  instantiation. 

Sharing  generics  causes  a  slight  execution  time  penalty  because  all  type 
attributes  must  be  indirectly  referenced  (as  if  an  extra  calling  argument 
were  added).  However,  it  substantially  reduces  compilation  time  in  most 
circumstances  and  reduces  program  size. 

Pragma  SUPPRESS_ALL  give  permission  to  the  implementation  to  suppress  all 
run-time  checks.  There  are  no  parameters  to  pragma  SUPPRESS  ALL.  It  is 
allowed  to  appear  immediately  within  a  declarative  part.  It's  effects  are 
equivalent  to  a  complete  list  of  SUPPRESS  pragmas,  each  naming  a  different 


C-8 


APPENDIX  F  OF  THE  Ada  STANDARD 


check. 

Pragma  OPT_LEVEL  controls  the  level  of  optimization  performed  by  the 
compiler.  This  pragma  takes  one  of  the  following  as  an  argument:  NONE, 
MINIMAL,  GLOBAL,  or  MAXIMAL.  The  default  is  MINIMAL.  NONE  produces 
inefficient  code  but  allows  for  faster  compilation  time.  MINIMAL  produces 
more  efficient  code  with  the  compilation  time  slightly  degraded.  GLOBAL 
produces  highly  optimized  code  but  the  compilation  time  is  significantly 
impacted.  MAXIMAL  is  an  extension  of  GLOBAL  that  can  produce  even  better 
code  but  may  change  the  meaning  of  the  program.  MAXIMAL  attempts  strength 
reduction  optimizations  that  may  raise  OVERFLOW  exceptions  when  dealing 
with  values  that  approach  the  limits  of  the  architecture  of  the  machine. 
The  pragma  is  allowed  within  any  declarative  part.  The  specified 
optimization  level  will  apply  to  all  code  generated  for  the  specifications 
and  bodies  associated  with  the  immediately  enclosing  declarative  part. 

In  general,  programs  should  be  developed  and  debugged  using  0PT_LEVEL 
(MINIMAL),  reserving  GLOBAL  and  MAXIMAL  for  a  thoroughly  tested  product. 

The  following  optimizations  are  performed  at  the  various  levels. 

OPTLEVEL  NONE: 

Short  circuit  boolean  tests 
Use  of  machine  idioms 
Literal  pooling 

OPTLEVEL  MINIMAL:  (in  addition  to  those  done  with  NONE) 

Binding  of  intermediate  results  to  registers 
Determination  of  optimal  execution  order 
Simplification  of  algebraic  expressions 
Re-association  of  expressions  to  collect  constants 
Detection  of  unreachable  instructions 
Elimination  of  jumps  to  adjacent  labels 
Elimination  of  jumps  over  jumps 

Replacement  of  a  series  of  simple  adjacent  instructions  by  a 
single  faster  complex  instruction 
Constant  folding 

0PT_LEVEL  GLOBAL:  (in  addition  to  those  done  with  MINIMAL) 

Elimination  of  unreachable  code 
Insertion  of  zero  trip  tests 
Elimination  of  dead  code 
Constant  propagation 
Variable  propagation 
Constraint  propagation 

Folding  of  control  flow  constructs  with  constant  tests 

Elimination  of  local  and  global  common  sub-expressions 

Move  loop  invariant  code  out  of  loops 

Reordering  of  blocks  to  minimize  branching 

Binding  variables  to  registers 

Detection  of  uninitialized  uses  of  variables 

Partial  folding  of  Boolean  expressions 

Direct  branching  to  exception  handlers 
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OPT_LEVEL  MAXIMAL:  (in  addition  to  those  done  with  GLOBAL) 

Comprehensive  strength  reduction 
Test  replacement 
Induction  variable  elimination 
Elimination  of  dead  regions 

Register  reallocation  and  redundant  move  elimination 
Instruction  scheduling  and  reordering 

Pragma  UNIVERSE  allows  the  specification  of  the  CX/UX  universe  for  a 
compilation  unit.  The  pragma  has  one  required  parameter,  the  literal 
denoting  the  desired  universe.  The  pragma  takes  the  form: 

pragma  UNIVERSE(universe_li teral) ; 

where  the  universeli teral  is  one  of  ucb  or  att.  Details  on  the  effects  of 
the  CX/UX  universeswitch  can  be  found  in  the  man  page  for  universe(l). 

Pragma  UNIVERSE  has  effects  at  compile  time,  link  time  and  execution  time. 
At  compile  time,  if  the  value  specified  differs  from  the  current  CX/UX 
universe  value  a  warning  message  is  printed.  At  link  time,  if  the  program 
contains  units  which  have  been  compiled  with  conflicting  values  of  pragma 
UNIVERSE  a  warning  message  is  printed.  Otherwise,  the  universe  will  be  set 
as  specified  by  the  pragma  for  the  duration  of  the  link  operation.  At 
execution  time,  a  call  to  the  CX/UX  setuniverse(2)  service  will  be 
performed  prior  to  the  elaboration  of  the  program's  library  packages  if  the 
program  contains  a  compilation  unit  marked  with  pragma  UNIVERSE  and  if 
conflicting  values  of  pragma  UNIVERSE  have  not  been  specified  in  any  other 
compilation  units.  Pragma  VOLATILE  accepts  a  list  of  simple  variable 
names,  which  the  compiler  assumes  to  occupy  volatile  storage  bases.  All 
subsequent  reads  and  writes  of  these  variables  will  result  in  memory 
references. 

IMPLEMENTATION-DEPENDENT  ATTRIBUTES 

HAPSE  has  defined  the  following  attributes  for  use  in  conjunction  with  the 
implementation-defined  pragma  SHARED_PACKAGE : 

P'KEY 
P'SHMID 
P ' LOCK 
P' UNLOCK 

where  the  prefix  P  denotes  a  package  marked  with  pragma  SHARED_PACKAGE . 

The  'KEY  attribute  is  an  overloaded  parameterless  function  which  returns 
the  key  used  to  identify  the  CX/UX  shared  segment  associated  with  the 
package.  One  specification  of  the  function  returns  the  predefined  type 
string,  and  returns  a  value  specifying  the  filename  used  in  the  key 
translation  (ftok(3C)).  If  an  integer  literal  key  was  specified  in  the 
pragma  shared_package  parameters,  this  function  returns  a  null  string.  The 
other  specification  of  the  function  returns  the  predefined  type 
universal_integer ,  and  returns  a  value  specifying  the  translated  integer 
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key.  The  latter  form  of  the  function  will  raise  the  predefined  exception 
PROGRAM_ERROR  if  the  shared  package  body  has  not  yet  been  elaborated. 

The  'SHM_ID  attribute  returns  the  shared  memory  identifier  obtained  by  the 
implementation  by  the  shmget(2)  service  call. 

The  'LOCK  and  'UNLOCK  attributes  are  parameterless  procedures  which 
manipulate  the  "state"  of  a  shared  package.  HAPSE  defines  all  shared 
packages  to  have  two  states:  LOCKed  and  UNLOCKed.  Upon  return  from  the 
'LOCK  procedure,  the  state  of  the  package  will  be  LOCKed.  If  upon 
invocation,  'LOCK  finds  the  state  already  LOCKed,  it  will  wait  until  it 
becomes  UNLOCKed  before  altering  the  state  and  returning.  'UNLOCK  sets  the 
state  of  the  package  to  UNLOCKed  and  then  returns.  At  the  point  of 
unlocking  the  package,  if  another  process  waiting  in  the  'LOCK  procedure 
has  a  more  favorable  CX/UX  priority,  the  system  will  immediately  schedule 
its  execution. 

Note  that  if  'LOCK  is  waiting,  it  may  be  interrupted  by  the  HAPSE  run-time 
system's  time  slice  for  tasks  which  may  cause  another  task  within  the 
process  to  become  active.  Eventually,  HAPSE  will  again  transfer  control  to 
the  'LOCK  procedure  in  the  original  task,  and  it  will  continue  waiting  or 
return  to  the  task. 

The  state  of  the  package  is  only  meaningful  to  the  'LOCK  and  'UNLOCK 
attribute  procedures  that  set  and  query  the  state.  A  LOCK  state  does  not 
prevent  concurrent  access  to  objects  in  the  shared  package.  These 
attributes  only  provide  indivisible  operations  for  the  setting  and  testing 
of  implicit  semaphores  that  could  be  used  to  control  access  to  shared 
package  objects.  CAUTION:  The  current  shared  memory  implementation  does 
not  allow  the  use  of  the  'LOCK  and  'UNLOCK  attributes  with  a  SHMRDONLY 
shared  memory  segment. 

HAPSE  provides  the  package,  shared_memory_support .  This  package  contains 
Ada  type,  subprogram  definitions,  and  interfaces  to  aid  the  user  in 
manually  interfacing  to  the  CX/UX  shared  memory  services. 

This  includes: 

System  defines  and  records  layouts  as  defined  by  the  CX/UX  C 
Programming  Language  include  files,  <sys/shm.h>  and  <sys/ipc-h>. 

Interface  specifications  to  shared  memory  system  calls:  shmbind, 
shmget,  shmat,  shmctl,  shmdt. 

Interface  specifications  to  the  CX/UX  binary  semaphore  operators: 
binsemget,  lockbinsem,  unlockbinsem. 
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SPECIFICATION  OF  PACKAGE  SYSTEM 


package  SYSTEM  is 

type  ADDRESS  is  private; 
type  NAME  is  (Harris_GCK) ; 

SYSTEM_NAME  :  constant  NAME  :=  Harris_88K; 

—  System-Dependent  Constraints 

STORAGE_UNIT  :  constant  :=  8; 

MEMORY  SIZE  :  constant  :=  3  221  225  469; 


—  System-Dependent  Named  Numbers 


MIN_INT 

MAX_INT 

MAX_DIGITS 

MAX_MANTISSA 

FINE_DELTA 

TICK 


constant  :=  -2_147_483_648 ; 
constant  :=  2_147_483_647 ; 
constant  :=  15; 
constant  :=  30; 
constant  :=  2.0**(-30); 
constant  :=  0.01; 


—  Other  System-dependent  Declarations 
subtype  PRIORITY  is  INTEGER  range  0  ..  9; 

MAX_REC_SIZE  :  INTEGER  :=  268435455;  —  16#0FFFFFFF# 

NOADDR  :  constant  ADDRESS  ; 

pragma  suppress(  elaborationcheck  ); 


—  The  following  functions  provide  conversions  to  "address" 

—  from  integer  values. 

function  LOGICALADDRESS  (i  :  integer)  return  ADDRESS  ; 


—  The  following  function  should  ONLY  be  used  to  supply  a 

—  machine  address  to  an  object's  address  clause  statement. 

—  The  parameter  is  an  integer  describing  the  physical  machine 

—  address  of  the  object. 

—  Optimization  of  subsequent  references  to  the  object  with  the 

—  address  clause  will  result  if  the  parameter  to  this  function 
--  is  an  integer  literal. 
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function  MACHINE_ADDRESS  (i  :  INTEGER)  return  ADDRESS  ; 

function  ADDR_GT  (A,  B  :  ADDRESS)  return  BOOLEAN  ; 

function  ADDR_LT  (A,  B  :  ADDRESS)  return  BOOLEAN  ; 

function  ADDR_GE  (A,  B  :  ADDRESS)  return  BOOLEAN  ; 

function  ADDR_LE  (A,  B  :  ADDRESS)  return  BOOLEAN  ; 

function  ADDR_DIFF  (A,  B  :  ADDRESS)  return  INTEGER  ; 

function  INCR_ADDR  (A  :  ADDRESS  ;  INCR  :  INTEGER)  return  ADDRESS  ; 
function  DECR_ADDR  (A  :  ADDRESS  ;  DECR  :  INTEGER)  return  ADDRESS  ; 
function  ">"  (A,  B  :  ADDRESS)  return  BOOLEAN  renames  ADDR_GT  ; 

function  "<"  (A,  B  :  ADDRESS)  return  BOOLEAN  renames  ADDR_LT  ; 

function  ">="  (A,  B  :  ADDRESS)  return  BOOLEAN  renames  ADDR_GE  ; 

function  "<="  (A,  B  :  ADDRESS)  return  BOOLEAN  renames  ADDR_LE  ; 

function  (A,  B  :  ADDRESS)  return  INTEGER  renames  ADDR_DIFF  ; 

function  (A  :  ADDRESS  ;  INCR  :  INTEGER)  return  ADDRESS 

renames  INCR_ADDR  ; 

function  (A  :  ADDRESS  ;  DECR  :  INTEGER)  return  ADDRESS 

renames  DECR_ADDR  ; 

pragma  inline  (ADDR_GT)  ; 
pragma  inline  (ADDRLT)  ; 
pragma  inline  (ADDRGE)  ; 
pragma  inline  (ADDRLE)  ; 
pragma  inline  (ADDRDIFF)  ; 
pragma  inline  (INCRADDR)  ; 
pragma  inline  (DECRADDR)  ; 
pragma  inline  (LOGICAL_ADDRESS)  ; 
pragma  builtin  (MACHINE_ADDRESS)  ; 

private 

type  ADDRESS  is  new  INTEGER; 

NOADDR  :  constant  ADDRESS  :=  0  ; 
end  SYSTEM; 


RESTRICTIONS  ON  REPRESENTATION  CLAUSES 
Pragma  PACK 

Pragma  PACK  is  fully  supported.  Objects  and  components  are  packed  to  the 
nearest  and  smallest  bit  boundary  when  pragma  PACK  is  applied.  Length 
Clauses  The  specification  T'SIZE  is  fully  supported  for  all  scalar  and 
composite  types,  except  for  floating  point.  For  floating  point,  access, 
and  task  types,  the  supplied  static  expression  must  conform  to  an  existing 
supported  machine  representation. 
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Type  Size 


floating  point  32  or  64 
access  32 

task  32 


T' SIZE  applied  to  a  composite  type  will  cause  compression  of  scalar 
component  types  and  the  gaps  between  the  components.  T'SIZE  applied  to  a 
composite  type  whose  components  are  composite  types  does  not  imply 
compression  of  the  inner  composite  objects.  To  achieve  such  compression, 
the  implementation  requires  explicit  application  of  T'SIZE  or  pragma  PACK 
to  the  inner  composite  type. 

Composite  types  which  contain  components  that  have  had  T'SIZE  applied  to 
them,  will  adhere  to  the  specified  component  size,  even  if  it  causes 
alignment  of  components  on  non  STORAGE_UNIT  boundaries. 

The  size  of  a  non-component  object  of  a  type  whose  size  has  been  adjusted, 
via  T'SIZE  or  pragma  PACK,  will  be  exactly  the  specified  size;  however,  the 
implementation  will  choose  an  alignment  for  such  objects  that  provides 
optimal  performance. 

Record  Representation  Cl^u'es 

The  simple  expressi<~  .  'cllowing  the  keywords  "at  mod"  in  an  alignment 
clause  specifies  the  oTORAGE_UNIT  alignment  restrictions  for  the  record; 
values  of  1,  2,  or  8  are  allowed. 

The  simple  expression  following  the  keyword  "at"  in  a  component  clause 
specifies  rne  STORAGE_UNIT  (relative  to  the  beginning  of  the  record)  at 
which  the  following  range  is  applicable.  The  static  range  following  the 
keyword  range  specifies  the  bit  range  of  the  component.  Components  may 
overlap  word  boundaries  (4  STORAGE_UNITs) .  Components  that  are  themselves 
composite  types  must  be  aligned  on  a  STORAGE_UNIT  boundary. 

A  component  clause  applied  to  a  component  that  is  a  composite  type  does  not 
imply  compression  of  that  component.  For  such  component  types,  the 
implementation  requires  that  T'SIZE  or  pragma  PACK  be  applied,  if 
compression  beyond  the  default  size  is  desired. 

Address  Clauses 

Address  clauses  are  only  supported  for  variables,  constants,  and  task 
entries. 

For  variables  and  constants,  both  logical  and  machine  addresses  are 
supported.  A  "logical  addresses"  refers  to  a  virtual  memory  address  in  the 
execution  program's  address  space.  A  "machine  addresses"  refers  to  a 
physical  memory  address. 

Logical  address  clauses: 
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The  function  LOGICAL_ADDRESS  is  defined  in  the  package  SYSTEM  to 
provide  conversion  from  INTEGER  values  to  ADDRESS  values  for  logical 
addresses  only. 

Both  static  and  variable  logical  addresses  are  supported. 

The  value  supplied  to  the  address  clause  must  be  a  valid  logical 
address  in  the  user's  program. 

Machine  addresses  clauses: 

When  a  machine  address  is  desired,  the  expression  supplied  on  the 
address  clause  MUST  be  an  invocation  of  the  function  MACHINE_ADDRESS, 
found  in  package  SYSTEM.  Any  other  expression  supplied  to  the  address 
clause  will  cause  it  to  be  interpreted  as  a  logical  address. 

Both  static  and  variable  machine  addresses  are  supported. 

The  argument  to  MACHINE_ADDRESS  must  be  a  valid  integer  physical 
memory  address. 

If  the  argument  to  MACHINE_ADDRESS  is  an  integer  literal,  then  static 
address  translation  can  occur,  thereby  removing  any  additional 
overhead  involved  in  accessing  the  variable  at  runtime. 

You  must  be  "superuser"  or  have  the  ACC_SHMBIND  bit  set  in  your  access 
vector  in  order  to  use  machine  address  clauses. 

WARNING:  It  is  the  user's  responsibility  to  ensure  that  the  supplied 
address  is  a  valid  physical  memory  address. 

Machine  addresses  clauses  are  implemented  via  CX  shared  memory 
segments,  which  are  bound  to  the  specified  physical  memory  address  at 
elaboration  time.  These  shared  memory  segments  are  removed  at  the  end 
of  normal  execution  of  a  program.  If  the  program  is  terminated 
abnormally,  the  user  is  responsible  for  removing  the  shared  memory 
segments  left  in  the  system  (see  ipcs(2),  ipcrm(2)). 


Interrupts 

Interrupt  entries  (UNIX  signals)  are  supported.  This  feature  allows  Ada 
programs  to  bind  a  UNIX  signal  to  an  interrupt  entry  by  using  a  for  clause 
with  a  signal  number.  There  is  not  any  protection  against  two  tasks 
binding  the  same  signal.  The  result  is  undefined.  Interrupt  entries 
should  not  have  any  parameters  and  can  be  called  explicitly  by  the  program. 
See  SIGVEC(2) . 

The  HAPSE  run-time  uses  SIGALRM  (14)  to  perform  time  slicing  and  delays. 

The  result  of  establishing  a  signal  handler  for  SIGALRM  is  undefined. 

The  following  example  program  uses  an  interrupt  entry  that  prints  a  message 
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when  the  process  receives  SIGINT. 

with  TEXT_I0,  SYSTEM; 
use  TEXT_I0; 
procedure  INTR  is 

—  This  program  waits  for  the  user  to  generate  SIGINT  (<C0NTR0L>C) 

SIGINT_NUMBER  :  constant  :=  2; 

task  SIGINT_HANDLER  is 
entry  SIGINT; 

for  SIGINT  use  at  SYSTEM . PHYSICAL_ADDRESS( SIGINT_NUMBER) ; 
end  SIGINT_HANDLER ; 
task  body  SIGINT_HANDLER  is 
begin 

accept  SIGINT; 

PUT_LINE( "Control-C  received"); 
end  SIGINT_HANDLER ; 

begin 
null ; 
end  INTR; 

OTHER  REPRESENTATION  IMPLEMENTATION-DEPENDENCIES 

The  ADDRESS  attribute  is  not  supported  for  the  following  entities:  static 
constants,  packages,  tasks,  and  entries.  Application  of  the  attribute  to 
these  entities  generated  a  compile  time  warning  and  a  value  of  0  at 
runtime. 

CONVENTIONS  FOR  IMPLEMENTATION-GENERATED  NAMES 
Implementation-generated  names  do  not  exist. 

UNCHECKED  PROGRAMMING 
UNCHECKED_CONVERSI ON 

The  following  describes  the  transfer  of  data  between  the  source  and  target 
operands  when  performing  unchecked  conversion.  When  possible,  the 
implementation  may  optimize  the  conversion  operation  such  that  no  transfer 
of  data  actually  occurs. 

The  implementation  considers  all  objects  of  simple  types  to  be  "right 
justified"  within  the  storage  allocated,  and  all  objects  of  composite  types 
to  be  "left  justified".  If,  for  alignment  reasons,  an  object  is  placed  in 
storage  which  is  larger  than  the  object's  'SIZE  value,  the  significant  bits 
of  an  object  of  a  simple  type  will  be  placed  in  the  low  order  bits  of 
storage,  right  justified,  with  any  padding  in  the  high  order  bits. 

Likewise,  should  an  object  of  a  composite  type  be  allocated  storage  which 
is  larger  than  the  type's  'SIZE,  the  significant  bits  will  be  placed  in  the 
high  order  bits,  and  any  padding  will  be  placed  in  the  low  order  bits. 
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Simple  Type  to  Simple  Type  Conversions 

For  all  access,  task,  and  scalar  types,  unchecked  conversion  is  implemented 
using  the  most  efficient  transfer  instruction  to  move  a  1,  2,  4,  or  8  byte 
object  to  its  destination,  unless  the  type  has  been  explicitly  given  a 
'SIZE  which  is  not  a  power  of  two,  in  which  case,  a  bit  transfer  will  be 
used . 

If  the  sizes  of  the  source  and  target  differ,  then  the  smallest  size  is 
used. 

If  the  target  has  a  larger  size  than  the  source,  the  source  is  moved  to  the 
low  order  bits  of  the  target.  If  the  target  type  is  signed,  then  the  high 
bit  of  the  source  is  sign  extended  through  the  high  bits  of  the  target. 
Otherwise,  the  high  order  bits  of  the  target  are  zero  filled. 

If  the  target  has  a  smaller  size  than  the  source,  the  low  order  bits  of  the 
source  are  copied  to  the  target. 

Composite  Type  to  Composite  Type  Conversions 

All  conversions  logically  occur  by  moving  bits  from  the  source  to  the 
target,  starting  at  the  highest  order  bit  of  the  source  and  target. 

If  the  sizes  of  the  source  and  target  differ,  then  the  smallest  size  is 
used. 

If  the  target  has  a  larger  size  than  the  source,  the  source  is  moved  to  the 
high  order  bits  of  the  target,  and  the  low  order  bits  of  the  target  are 
zero  filled. 

If  the  target  has  a  smaller  size  than  the  source,  the  high  order  bits  of 
the  source  are  copied  to  the  target. 

Simple  Type  to  Composite  Type  Conversions 

Conversions  from  simple  types  to  composite  types  are  implemented  by  moving 
the  low  order,  right  justified,  bits  of  the  source  to  the  high  order,  left 
justified  bits  of  the  target. 

If  the  sizes  of  the  source  and  target  differ,  then  the  smallest  size  is 
used . 

If  the  target  has  a  larger  size  than  the  source,  the  source  is  moved  to  the 
high  order  bits  of  the  target,  and  the  low  order  bits  of  the  target  are 
zero  filled. 

If  the  target  has  a  smaller  size  than  the  source,  the  low  order  bits  of  the 
source  are  copied  to  the  target. 

Composite  Type  to  Simple  Type  Conversions 
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Conversions  fiom  composite  types  to  simple  types  are  implemented  by  moving 
the  high  order,  left  justified,  bits  of  the  source  to  the  low  order,  right 
justified  bits  of  the  target. 

If  the  sizes  of  the  source  and  target  differ,  then  the  smallest  size  is 
used. 

If  the  target  has  a  larger  size  than  the  source,  the  source  is  moved  to  the 
low  order  bits  of  the  target.  If  the  target  type  is  signed,  then  the  high 
bit  of  the  source  is  sign  extended  through  the  high  bits  of  the  target. 
Otherwise,  the  high  order  bits  of  the  target  are  zero  filled. 

If  the  target  has  a  smaller  size  than  the  source,  the  high  order  bits  of 
the  source  are  copied  to  the  target. 

UNCHECKED_DEALLOCATION  UNCHECKED_DEALLOCATION  is  supported.  In  the  current 
release,  it  has  no  effect  on  access  objects  which  designate  tasks. 


IMPLEMENTATION  CHARACTERISTICS  OF  I/O  PACKAGES 
Implementation-Dependent  Characteristics  of  DIRECT  I/O 

Instantiations  of  DIRECT_IO  use  the  value  MAX_REC_SIZE  as  the  record  size 
(expressed  in  STORAGE  UNITs)  when  the  size  of  ELEMENTTYPE  exceeds  that 
value.  For  example,  Tor  unconstrained  arrays  such  as  a  string  where 
ELEMENT_TYPE' SIZE  is  very  large,  MAX_REC_SIZE  is  used  instead. 

MAX  RECSIZE  is  defined  in  SYSTEM  as  4_000_000  storage  units. 
Implementation-Dependent  Characteristics  oT  SEQUENTIAL  I/O 

Instantiations  of  SEQUENTIAL_IO  use  the  value  MAX_REC_SIZE  as  the  record 
size  (expressed  in  STORAGE  UNITs)  when  the  size  of  ELEMENTTYPE  exceeds 
that  value.  For  example,  Tor  unconstrained  arrays  such  as  a  string  where 
ELEMENTTYPE ' SIZE  is  very  large,  MAX_REC  SIZE  is  used  instead. 

MAX_REC_SIZE  is  defined  in  SYSTEM  as  4_0(50_000  storage  units. 

MACHINE  CODE  INSERTIONS 

The  general  definition  of  the  package  MACHINE  CODE  provides  an  assembly 
language  interface  for  the  target  machine  including  the  necessary  record 
types  needed  in  the  code  statement,  an  enumeration  type  containing  all  of 
the  opcode  mnemonics,  a  set  of  register  definitions,  and  a  set  of 
addressing  mode  functions.  Also  supplied  (for  use  only  in  units  that  WITH 
MACHINE  CODE)  is  the  implementation  defined  attribute  'REF. 

Machine  code  statements  accept  operands  of  type  OPERAND,  a  private  type 
that  forms  the  basis  of  all  machine  code  address  formats  for  the  target. 

The  general  syntax  for  a  machine  code  statement  is 

CODEn' (opcode,  operand  {,  operand}); 
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In  the  example  shown  below,  CODE_3  is  a  record  'format'  whose  first 
argument  is  an  enumeration  value  of  the  type  OPCODE  followed  by  three 
operands  of  type  OPERAND. 

code_3'  (sub,  r4,  r4,  +1); 

The  opcode  must  be  an  enumeration  literal  (ie.,  it  cannot  be  an  object,  an 
attribute,  or  a  rename).  An  operand  can  only  be  an  entity  defined  in 
MACHINECODE  or  by  the  'REF  attribute. 

For  an  object,  arguments  to  any  of  the  functions  defined  in  MACHINE_CODE 
must  be  static  expressions,  string  literals,  or  the  functions  defined  in 
MACHINECODE .  The  'REF  attribute  may  not  be  used  as  an  argument  in  any  of 
these  functions. 

The  'REF  attribute  denotes  the  effective  address  of  the  first  of  the 
storage  units  allocated  to  the  object.  For  a  label,  it  refers  to  the 
address  of  the  machine  code  associated  with  the  corresponding  body  or 
statement.  The  attribute  is  of  type  OPERAND  defined  in  the  package 
MACHINE_CODE  and  is  allowed  only  within  a  machine  code  procedure.  'REF  is 
only  supported  for  simple  objects  and  labels. 

Registers  -  The  full  set  of  32  general  purpose  registers  for  the  88K  target 
is  supported  (RO  through  R31). 

Addressing  modes  -  All  of  the  88K  addressing  modes  are  supported  by  the 
compiler.  They  are  accessed  through  the  following  functions  provided  in 
MACHINECODE. 

SPECIFICATION  OF  THE  PACKAGE  MACHINE_CODE 
package  machinecode  is 
type  opcode  is  ( 

add,  addci,  addcio,  add_co,  addu, 
addu_ci,  adducio,  addu_co,  and_r,  andc,  and  u,  bbO, 
bbOn,  bbl,  bbl_eq,  bbl_ne,  bbl_gt,  bbl_le,  bSllt,  bblge, 
bbl_hi,  bbl  Is,  bbl_lo,  bbl_hs,  bbl_n,  bbl_n_eq,  bbl_n_ne, 
bbl_n_gt,  bhl_n_le,  bbl_n_lt,  bbl_n_ge,  bbl_n_hi,  bbl_n  Is, 
bbl_n  lo,  bbl_n_hs,  bend  0,  bcnd_10,  bcnd_ll,  bcnd_15,  Scnd_4, 
bcnd_5,  bcnd_6,  bcnd_7,  Ucnd_8,  bcnd_9,  bend  eqO,  bcndgeO, 
bcnd_gt0,  bcnd_le0,  bcnd_lt0,  bcnd_ne0,  bcnd~n_0,  bcnd_n_10, 
bcnd_n_ll,  bcnd_n_15,  bcnd_n_4,  bcnd_n_5,  bcnd_n_6,  bcnd_n_7, 
bcnd_n_8,  bcnd_n_§,  bcnd_n_eq0,  bcnd_n_ge0,  bcnd_n_gt0,  bcnd_n_le0, 
bcnd_n_lt0,  bcnd_n_ne0,  br,  br_n,  bsr,  bsr_n, 
clr,  emp,  div,  divu,  ext,  extu,  fadd_ddd, 

fadd_dds,  fadd_dsd,  fadd_dss,  fadd_sdd,  fadd  sds,  fadd_ssd,  fadd_sss, 

fcmp_sdd,  fcmp_sds,  fcmp_ssd,  fcmp_sss,  fdiv~ddd,  fdiv_dds,  fdiv  dsd, 

fdiv_dss,  fdiv  sdd,  fdiv  sds,  fdiv_ssd,  fdiv~sss,  ffO,  ffl,  fltJJs, 

fit  ss,  fmul_d5d,  fmul_d3s,  fmul_dsd,  fmul_dss,  fmul_sdd,  fmul_sds, 
fmul_ssd,  fmul_sss,  fsub_ddd,  fsub_dds,  fsub_dsd,  fsub  dss,  fsub_sdd, 

fsub_sds,  fsub_ssd,  fsub_sss,  int  sd,  int_ss7  jmp,  jmp_n, 
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jsr,  jsr  n,  Id,  Id  b,  ld_bu,  ld_d,  ld_h,  ld_hu,  Ida, 
lda_b,  l5a_d,  lda_H,  mak,  mask,  mask_u,  mul,  nint_sd, 
nint_ss,  or_r,  or_c,  or_u,  rot,  set,  st,  st_b, 

st_d,  st_h,  sub,  sub_ci,  sub_cio,  sub_co,  subu,  subu_ci,  subu_cio, 
subu_co,  tbO,  tbl,  tbnd,  tcnd_0,  tcnd_10,  tcnd_ll,  tcnd_15, 
tcnd~4,  tcnd_5,  tcnd_6,  tcnd_7,  tcnd_8,  tcnd_9,  tcnd_eqO,  tcnd_geO, 
tcnd_gtO,  tcnd_leO,  tcnd_ltO,  tcnd_neO,  trnc_sd,  trnc_ss,  xmem, 
xmem~bu,  xor_r,  xor_c,  xor_u,  fldcr,  fstcr,  fxcr,  ld_usr,  ld_b_usr, 
ld_bu_usr,  ld_d_usr,  ld_h_usr,  ld_hu_usr,  ldcr,  rte,  st_usr,  st_b_usr, 
st  d  usr,  st  h  usr,  stcr,  xcr,  xmem_usr,  xmem_b_usr 


type  scale_select  is  (unsealed,  scaled)  ; 
type  operand  is  private  ; 

type  operand_seq  is  array  (positive  range  <>)  of  operand  ; 
n  :  positive  ; 


—  Instruction  formats. 


type  codeO  (op  :  opcode)  is 
record 
null  ; 

end  record  ; 

type  codel  (op  :  opcode)  is 
record 

oprndl  :  operand  ; 
end  record  ; 

type  code_2  (op  s  opcode)  is 
record 

oprnd_l  :  operand  ; 
oprnd_2  :  operand  ; 
end  record  ; 

type  code_3  (op  :  opcode)  is 
record 

oprnd_l  :  operand  ; 
oprnd_2  :  operand  ; 
oprnd_3  :  operand  ; 
end  record  ; 

type  code_4  (op  :  opcode)  is 
record 

oprndl  :  operand  ; 
oprnd_2  :  operand  ; 
oprnd_3  :  operand  ; 
oprnd_4  :  operand  ; 
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end  record  ; 


—  Registers. 


rO 

constant  operand 

rl 

constant  operand 

r2 

constant  operand 

r3 

constant  operand 

r4 

constant  operand 

r5 

constant  operand 

i6 

constant  operand 

r7 

constant  operand 

r8 

constant  operand 

r9 

constant  operand 

rlO 

constant  operand 

rll 

constant  operand 

rl2 

constant  operand 

rl3 

constant  operand 

rl4 

constant  operand 

rl5 

constant  operand 

rl6 

constant  operand 

rl7 

constant  operand 

r!8 

constant  operand 

rl9 

constant  operand 

r20 

constant  operand 

r21 

constant  operand 

r22 

constant  operand 

r23 

constant  operand 

r24 

constant  operand 

r25 

constant  operand 

r26 

constant  operand 

r27 

constant  operand 

r28 

constant  operand 

r29 

constant  operand 

r30 

constant  operand 

r31 

constant  operand 

sp 

:  constant  operand 

—  Addressing  modes. 

type  f ive_bit_range  is  nev  integer  range  0..31  ; 

—  Assembler  Notation  : 

lol6(name) 

function  ext  lo  (name  :  string)  return  operand  ; 
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—  Description  : 

Provides  the  low  16  bits  of  the  address  of  the  external 
object  denoted  by  name. 


—  Assembler  Notation  : 
hil6(name) 

function  ext_hi  (name  :  string)  return  operand  ; 

—  Description  : 

Provides  the  high  16  bits  of  the  address  of  the  external 
object  denoted  by  name. 


—  Assembler  Notation  : 
lol6(xxx) 

function  absollo  (disp  :  integer)  return  operand  ; 

—  Description  : 

Provides  the  low  16  bits  of  the  address  specified. 


—  Assembler  Notation  : 
hil6(xxx) 

function  absolhi  (disp  :  integer)  return  operand  ; 

—  Description  : 

Provides  the  high  16  bits  of  the  address  specified. 


—  Assembler  Notation  : 

Rn,0 

function  indr  (addr_reg  :  operand)  return  operand  ; 

—  Description  : 

The  address  of  the  operand  is  in  the  address  register  specified 
by  the  register  field. 


—  Assembler  Notation  : 

—  Rn,I16 
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function  disp  (reg  :  operand  ;  disp  :  integer)  return  operand  ; 

—  Description  : 

The  address  of  the  operand  is  the  32-bit  unsigned  sum  of  the 
address  in  the  address  register  and  the  zero-extended  16-bit 
displacement  integer. 


—  Assembler  Notation  : 

Rn, lol6(name) 

function  indr_lo  (addrreg  :  operand  ;  name  :  string)  return  operand  ; 
—  Description  : 

The  address  of  the  operand  is  in  the  address  register  specified 
by  the  register  field,  indexed  by  the  low  16  bits  of  the 
displacement  of  the  external  specified  by  "name".  A  typical 
sequence  to  load  the  value  of  and  external  variable  might  be: 

code_3'  (or_u,  r20,  rO,  ext_hi("name"))  ; 
code  2'  (Id,  r21,  indr  lo(20, "name"))  ; 


—  Assembler  Notation  : 

Rn ,  Rn 

function  index  (basereg  :  operand  ; 

indexreg  :  operand)  return  operand  ; 


—  Description  : 

The  address  of  the  operand  is  the  sum  of  the  address  in  the  address 
register  and  the  32-bit  contents  of  the  index  register. 

Normal  unsigned  32  bit  address  arithmetic  is  used. 


—  Assembler  Notation  : 

Rn [ Rn ] 

function  index  (base_reg  :  operand  ; 

index_reg  :  operand  ; 

scale  factor  :  scale_select)  return  operand  ; 


—  Assembler  Notation  : 

—  V5<05> 

function  bit_field  (width  :  five_bit_range  ; 

offset  :  five  bit  range)  return  operand  ; 
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—  Assembler  Notation  : 

IMM16 

An  16-bit  unsigned  immediate  operand 
function  "+"  (right  :  integer)  return  operand  ; 


private 

type  operand  is  new  integer  ; 


rO 

constant  operand 

=  0 

rl 

constant  operand 

=  1 

r2 

constant  operand 

=  2 

r3 

constant  operand 

=  3 

r4 

constant  operand 

=  4 

r5 

constant  operand 

=  5 

r6 

constant  operand 

=  6 

r7 

constant  operand 

=  7 

r8 

constant  operand 

=  8 

r9 

constant  operand 

=  9 

rlO 

constant  operand 

=  10 

rll 

constant  operand 

=  11 

rl2 

constant  operand 

=  12 

rl3 

constant  operand 

=  13 

rl4 

constant  operand 

=  14 

rl5 

constant  operand 

=  15 

rl6 

constant  operand 

=  16 

rl7 

constant  operand 

=  17 

rl8 

constant  operand 

=  18 

rl9 

constant  operand 

*  19 

r20 

constant  operand 

»  20 

r21 

constant  operand 

*  21 

r22 

constant  operand 

*  22 

r23 

constant  operand 

=  23 

r24 

constant  operand 

=  24 

r25 

constant  operand 

=  25 

r26 

constant  operand 

=  26 

r27 

constant  operand 

=  27 

r28 

constant  operand 

=  28 

r29 

constant  operand 

=  29 

r30 

constant  operand 

=  30 

r31 

constant  operand 

=  31 

sp  :  constant  operand  :=  31  ; 

pragma  builtin  (absol  lo)  ; 
pragma  built_in  (absol~hi)  ; 
pragma  builtin  (disp)  ; 
pragma  built_in  (ext_lo)  ; 
pragma  built  in  (ext_hi)  ; 
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pragma  built_in  (index)  ; 
pragma  built_in  (indr)  ; 
pragma  built_in  (indr_lo)  ; 
pragma  built_in  ("+")  ; 

end  machine  code  ; 
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